## 🏗️ Architecture

### Проект

#### Единообразие для разных окружений или данные разных окружений в одном файле как промежуточный шаг

На примере Rails проекта по умолчанию при создании проекта есть файлы

```sh
config/application.rb
config/environments/development.rb
config/environments/production.rb
config/environments/test.rb
```

это порождает то что в разных окружениях будут разные настройки
когда придерживаемся единообразия, то больше шансов обнаружить проблемы своевременно и съэкономить на издержках

в таком случае мы можем избавить от папки `environments` и перенести все настройки в `application.rb`

самый простой путь для начала перенести все без изменений, обернув в проверки по окружениям

```ruby
if Rails.env.test?
  ...
elsif Rails.env.development?
  ...
end
```

это все приводит к тому что настройки для разных окружений оказываются в одном файле, но не обеспечивает единообразия

в идеале избавить по максимум от специальных настроек, и проверок по окружениям

но неизбежные отличия, уже будет необходмо вынести в отдельные файлы, снова, но уже будет меньше отличий
к этому будет придти сложнее, и можно откладывать, пока не получится использовать один билд в разных окружениях и лишь потом менять конфиги, например при деплое в разные окружения, что сократит время расскатки и упростит правки конфигов при работах

#### Начинать меньше чем с MVP для грамотной архитектуры

При создании проекта, от функционала надо оставлять даже меньше чем просто MVP, если не получается организовать архитекутуру легко.
То есть нормально если первая версия даже будет не релизной, так как надо заложить правильное ядро.
Проблема функционала что важное выпадает из фокуса и сложно его организовать.

#### Комментарии плохо, логи хорошо

Есть популярное мнение что комментари писать плохо, код должен быть понятен без комментариев, здесь соглашусь, это в 2 раза лучше
но сформулирую так, если заменить комментариии логами, вот тогда код станет 4 раза лучше